1. Field of the Invention
The present invention relates to a technique for maintaining the integrity of a set of related objects being modified by an object oriented application. More particularly, the present invention relates to a technique for maintaining the consistency of objects in a persistent store of objects while a user or application is modifying a portion of a persistent store of objects.
2. Description of the Related Art
In certain object oriented programming environments, such as Java and Smalitalk, programs basically comprise a set of instances of classes. (Java is a trademark of Sun Microsystems, Inc.) These instances are often referred to as objects. A class or instance of a class comprises both data (for example, in the form of data members for Java objects and instance variables for Smalitalk objects) and function (in the form of methods). Once an application or program is initiated, execution is carried out by sending messages between objects to request execution of a method in order to obtain data, perform a function, etc.
In Java and Smalltalk, execution of a program requires an appropriate virtual machine, which can be thought of as being analogous to a software computer or a microprocessor. The virtual machine is tailored for the platform (such as OS/2 or Windows), or is tailored for the CPU itself (a Pentium microprocessor, for example) and thus does not need a platform. (OS/2 is a registered trademark of the International Business Machines Corporation (IBM), Windows is a trademark of Microsoft Corporation, and Pentium is a trademark of Intel Corporation.) In either case, this is transparent to the user and her applications, since the user's applications will execute in whatever environment the virtual machine is found/has been tailored for. Thus, the applications or programs are platform independent, in that they are written for execution relative to a virtual machine and are not bound to being executed on a particular platform. So wherever their associated virtual machine is present, the applications or programs will execute. This is one of the key advantages of programming languages like Smalltalk and Java.
One drawback to these languages is the speed at which an application or program written in these languages is executed at runtime. These programs are not compiled in the traditional sense like a C language program, but rather are interpreted at execution (runtime). A number of techniques have been devised to speed up the execution, such as just-in-time compilers, partial compilation of methods which execute basic functions, etc.
Another feature of these languages which effects the execution speed is the requirement that the classes which comprise a program or application must be "loaded" just prior to their execution. This is more of a problem for Java programs than for Smalltalk programs, as the loading process for a Java class when it is first initiated (first required by an application being executed) is a relatively complex and time consuming process; instances of all the classes in a Smalltalk application are loaded when the application is initiated as part of the application's "image".
As object oriented technology, especially Java and Smalltalk technology, becomes more robust and mature, requirements placed upon object oriented applications have increased. It is relatively a simple matter for a single Java or Smalltalk program to be opened and executed all by itself and then terminated when it is no longer required. The logic is self-contained in the program, and the links to necessary data can be dealt with during the creation of the program. But in enterprise environments, the demands are much more severe. This is especially true for objects which contain data which will be used by a number of programs. Data from relational databases can be maintained in the form of objects in order to prevent programmers from having to deal directly with the tables and columns, which are the forms in which data is stored in relational databases, and the relationships between tables and columns.
When data from a relational database or other data store is mapped to an object representation for applications, the data store becomes the place which holds the permanent or persistent state of the object. This data store is referred to as a persistent store. One problem associated with maintaining a persistent store is that data is not static. For example, the information that is maintained in objects of a persistent store can be customer data, employee information, stock market information, etc. This data changes all the time. This data may be updated by traditional batch and transactional applications and by client/server applications.
Accordingly, one problem that must be addressed with respect to persistent stores is how to execute programs with data from objects in a persistent store when the objects in the persistent store are being updated. More particularly, this problem is to prevent the programs from being executed using partially updated data or data that has been entered but not reviewed for accuracy, etc. Coordinating the changes to objects and maintaining the consistency of those objects is a difficult problem. Changes to the objects must be applied in an atomic (simultaneous) and consistent manner. These changes are logically related within the application, representing change from the application's point of view.
One approach that has been used in addressing this problem has been to implement support for "transactions". A transaction represents a logical group of changes to one or more objects that will be applied in an atomic manner. When a transaction is complete, all of the changes are implemented at once, so that all of the affected objects are changed at substantially the same time, or the transaction can be canceled and no changes made to any of the objects.
Most systems which support transactions permit multiple active transactions to be carried out within the system. Traditional transaction systems are effective at managing the consistency of transactions between applications, by controlling the updates to the data store. In object-oriented environments, however, there may be multiple transactions required within a single application, or execution space. In a client/server environment, a single server application may serve many clients, each operating with an associated transaction. In a complex GUI (graphical user interface) application, multiple windows may be displaying or updating common objects using independent transactions. This requires a new level of coordination. The transaction framework must then enforce rules regarding collisions between transactions when two transactions attempt to modify the same data within an object. Such systems maintain the consistency of persistent data with the whole application, but do not control the visibility of changes effected by transactions within the application. This approach requires intervention by the developer to ensure that his transaction/program is not affected by changes being made by another transaction. The application developer must design his application or GUI to ensure that changes from other transactions are not accidentally displayed, and may have to artificially delay changes to objects so as to not affect other active transactions.
Accordingly, a need exists for a technique for a transaction framework which automatically handles potential collisions between transactions and permits execution of applications without data contamination and with a minimum of user intervention.